Purpose

The Community page triggered one extra database query per published build to load its components, an N+1 problem: showing 20 builds took about 21 queries, growing with the number of builds. This PR batches those lookups so the query count stays constant.

Changes

• Add a per-request DataLoader (createBuildPartsLoader in resolvers.ts) that fetches the parts of all requested builds in one parameterized query.
• Create a new loader for every request in index.ts, so results are not cached between requests.
• Add the dataloader dependency.
• Add buildPartsBatching.test.ts, which runs the real builds { parts } query through Apollo and checks the results and the number of queries. Update the Build.parts test in resolvers.test.ts to use the loader.

Loading 20 builds with their parts now takes 2 queries (one for the builds, one for all their parts) instead of 21.

Related issues

Closes #100

Verification

• npm test: all 85 tests pass. The new tests show exactly 2 queries for 1, 5, 20 and 100 builds, that every build gets its own parts in category order, that shared parts are fetched once, and that no parts query runs when no build has parts.
• npx tsc --noEmit and npx eslint .: clean.

Screenshots

Not applicable

Checklist

• I have reviewed my own changes.
• The changes meet the linked issue's acceptance criteria, where applicable.
• I have verified the changes and recorded the results above.
• I have added or updated tests where needed.
• I have updated documentation where needed.
• I have included screenshots for visual changes, or marked them not applicable.